There is currently a trend of migrating packet data communication onto low bandwidth networks such as cellular wireless networks, for example those specified by 3GPP. These networks can be used for multimedia sessions which are typically controlled by a protocol known as SIP (Session Initiation Protocol). SIP is an IETF standard which dictates the nature of messages which are transferred between multimedia devices in the network.
Multimedia devices may exchange SIP messages directly, or more often via network intermediates known as proxies. SIP proxies assist by routing SIP messages to the correct end point. End multimedia devices (which can send or receive) usually have a Default Proxy through which all outgoing and incoming SIP messages are routed. This default proxy can handle incoming messages when the device itself is not available (eg. route to voicemail server etc).
The SIP protocol includes end-to-end security capabilities (S/MIME) (Secure Multipurpose Interent Mail Extentions) which allow part of a message to be encrypted using a Public Key of the intended recipient. Other parts of the message remain unencrypted in order that they can be processed by intermediate entities (proxies) which assist in routing the message to the intended recipient.
In order to understand this more fully, it is useful to understand the SIP message format. FIG. 1 shows a schematic view of a SIP message format. The SIP message 10 includes message headers 12 and a message body 14,14′ etc.
The SIP message follows common internet application layer message format and is similar to Internet Mail and HTTP. Message headers carry routing information and protocol machinery and are used by the proxies. Message bodies carry information end-to-end between multimedia devices, e.g. session parameters. The message is text encoded and the message bodies are formatted using MIME and security protected using S/MIME.
The S/MIME standard has predominantly been developed for securing Internet Mail. It allows the message body to be signed and therefore integrity protected and/or encrypted and therefore confidentiality protected. The proxies do not look at the message bodies, so the content and any associated encryption is transparent to proxies. Three common types of S/MIME protected message body are the Session Description Protocol (application/SDP) and SIP messages themselves (message/sip) or fragments of SIP messages (message/sipfrag).
The Session Description Protocol contains session parameters (media type, format, addresses etc.), possibly including encryption keys for the media.
Message bodies may also contain a copy of (parts of) the SIP Message Headers which can be compared with the received message headers to see if anything has been modified by the proxies or indeed if there have been any attacks on the SIP message.
Integrity protection is one of the most important applications. In addition, Encryption is needed for SDP to protect encryption keys and may be needed for SIPFRAGS's which contain additional headers for end-to-end use.
Key exchange protocols, e.g. MIKEY, can be embedded in SDP. MIKEY does not require secure transport, but does support an ‘unprotected mode’ for operation over secure transport such as S/MIME protected SDP
The effect of S/MIME on a SIP message can be seen schematically in FIG. 2. The protected SIP message 20 includes message headers 22 and at least one message body wrapper 24. The message body wrapper includes an encrypted body 26 and a digital signature 28. The encryption and integrity protection afforded by this S/MIME is base on Public Key Technology. This requires that a certificate of the sender in included in the integrity protected message along with the signature and the certificate of the recipient is needed before the encrypted message can be sent.
3GPP have adopted SIP for their IP Multimedia Subsystem and it is likely that S/MIME will soon be adopted although there are some problems associated with this which will be addressed in greater detail below.
Another vital part of the SIP protocol which is relevant to this invention is SIP compression.
SIP messages use a highly inefficient text encoding method and as such are very verbose. SIGCOMP is a standardised compression mechanism for SIP messages, including their SDP bodies. This standardised compression mechanism has been found to be especially useful for low-bandwidth links as such as cellular wireless as used in the 3GPP IMS standard. SIGCOMP is used link-by-link i.e. between an end device (UA) and first proxy or between pairs of proxies. In order for SIGCOMP top be used for the first message sent, the sender must know, a priori, that the receiver or proxy supports SIGCOMP.
The SIGCOMP Messages have a number of features that are of relevance to this invention.
The first SIGCOMP message contains instructions for the recipient to decompress the message. These are in the form of a special bytecode to be run on a ‘Universal Decompressor Virtual Machine’ (UDVM). Typically the instructions are between 30 and 300 bytes, depending on the compression scheme chosen by the sender. Subsequent messages rely on the state at the receiver created by previous messages, including the decompression code uploaded with the first message. The compression efficiency increases greatly as more messages are sent and more state is built up. Some ‘initial state’, in the form of a static dictionary of common SIP/SDP phrases, can also be assumed.
At present, SIP messages between a 3GPP client and the first proxy benefit from encryption over the wireless link according to the 3GPP wireless packet data standards. Standard techniques defined by the IETF such as IPSEC or TLS can also be used to confidentiality protect the message between client and first proxy. 3GPP has adopted a compression scheme for SIP messages to reduce the bandwidth used by SIP signalling on the radio link between client and first proxy. This compression would be applied after any partial end-to-end encryption (S/MIME) but before the first-hop encryption (3GPP radio encryption and IPSEC or TLS).
In the drive for 3GPP to adopt SIP encryption and compression as currently defined in the SIP protocol a number of problems have been identified.
Use of end-to-end S/MIME encryption within the 3GPP IMS effectively negates the effectiveness of SIP compression on the radio link. The gains from SIP compression are expected to be very significant (SIP is very compressible), and so compression is expected to be essential in delivering reasonable message transmission times and hence reasonable call setup times.
In addition, compression relies on patterns and repeated text in the message to be compressed and encryption removes any such patterns/repetition. Thus, encrypted parts of the message will not compress. This is a major barrier to the introduction of S/MIME encryption into 3GPP IMS or other low-bandwidth applications.